Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update package metadata #1690

Merged
merged 3 commits into from
Nov 2, 2022
Merged

Conversation

ofek
Copy link
Contributor

@ofek ofek commented Oct 24, 2022

Background

Hello there! The Python packaging ecosystem has standardized on the interface for build backends (PEP 517/PEP 660) and the format for metadata declaration (PEP 621/PEP 631). As a result, the execution of setup.py files is now deprecated.

So, I'm spending my free time updating important projects so that they are modernized and set an example for others 😄

related: jazzband/help#313

Summary of changes

This implements PEP 621, obviating the need for setup.py (see note), setup.cfg, and MANIFEST.in. The build backend hatchling (of which I am a maintainer in the PyPA) is now used as that is the default in the official Python packaging tutorial. Hatchling is available on all the major distribution channels such as Debian, Fedora, Arch Linux, conda-forge, Nixpkgs, Alpine Linux, FreeBSD/OpenBSD, Gentoo Linux, MacPorts, OpenEmbedded, Spack, MSYS2, etc.

Notes

@ofek ofek force-pushed the modernize-metadata branch from 4e855d0 to 12fa55c Compare October 24, 2022 03:41
Copy link
Member

@matthiask matthiask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I like the general direction. I have yet to start converting any packages to the new format so I'm not able to judge if this is the best way to do it.

I have never heard about hatch or hatchling before. I see that it is a pypa repository, and this makes me feel warm and fuzzy inside :) so that's good. But I've certainly seen alternative build systems being used. Why should we use hatchling? (As you see I do not have a strong opinion here myself.)

I remember a discussion re. using something like this in Django proper. It was judged to be too early. I think django-debug-toolbar may be a good place to shake out the last (ha!) bugs but it still is a relatively high-profile project for Django users and I am wary to break things. Is the "new way" stable enough?

I don't know about leaving setup.py in there. GitHub seems to require it. But, if you leave it in there, you should probably add a sys.exit(...) above the commentary that the lines below will never be executed, otherwise they may be :-)

Thanks!

Copy link
Contributor

@hugovk hugovk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

That would make it easier to diff pyproject.toml across different Jazzband projects.

(I especially found https://github.com/abravalheri/validate-pyproject helpful when migrating to setup.cfg to pyproject.toml, could be useful in the future too?)

@tim-schilling
Copy link
Member

I don't have a strong opinion one way or another for packaging, but it seems like hatch is mature enough for us to use. I would suggest us running a test with test.pypi.org first. I've made a request to the owner of the django debug toolbar package on test.pypi.org to add me as an owner. If I'm able to get those permissions, I'll add you as well @matthiask.

@ofek
Copy link
Contributor Author

ofek commented Oct 24, 2022

Why should we use hatchling?

Not a complete list but here's from a recent comment -

Hatchling:

  • Supports static analysis tools for editable installations by default whereas the new setuptools does not i.e. it requires enabling an option for IDEs to work.
  • Uses Git-style glob patterns rather than stdlib globs to better match user expectations.
  • Allows easy and explicit control of what gets shipped in the sdist target whereas with setuptools it's an objectively confusing mix of conditional wheel options and a MANIFEST.in file.

I don't know about leaving setup.py in there.

Can I remove it?

@matthiask
Copy link
Member

Hatchling: [...]

Thanks!

Can I remove it?

I think it probably makes more sense to copy urllib3 there as well? See community/community#6456

@ofek
Copy link
Contributor Author

ofek commented Oct 24, 2022

Done!

@ofek
Copy link
Contributor Author

ofek commented Oct 25, 2022

@hugovk

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

Can we do that in a separate PR?

@hugovk
Copy link
Contributor

hugovk commented Oct 25, 2022

Sure!

@tim-schilling
Copy link
Member

@matthiask It'll take at least one more week until I have ownership of the test pypi repo. Do you want to do a release with the code before this change, then this after we test the release process on test.pypi.org? Or batch it all together?

@matthiask
Copy link
Member

@tim-schilling I think it's fine to batch it. We can always push another release or revert in the worst case.

@ofek
Copy link
Contributor Author

ofek commented Oct 29, 2022

another just merged prettytable/prettytable#212

docs/contributing.rst Outdated Show resolved Hide resolved
Copy link
Member

@tim-schilling tim-schilling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright I'm good with this. Thank you for the PR! @matthiask I don't feel strongly enough about testing with test.pypi.org to stop us from releasing this.

@matthiask matthiask merged commit 602f475 into django-commons:main Nov 2, 2022
@matthiask
Copy link
Member

Me neither, let's merge it then. Thanks all!

@ofek ofek deleted the modernize-metadata branch November 2, 2022 20:04
@pauloxnet
Copy link
Member

Great. Can we create a recipe with steps to apply this update in other jazzband packages ?

@ofek
Copy link
Contributor Author

ofek commented Nov 2, 2022

@hugovk
Copy link
Contributor

hugovk commented Nov 2, 2022

@hugovk

One suggestion: shall we add https://github.com/tox-dev/pyproject-fmt/ to pre-commit to consistently format pyproject.toml?

Can we do that in a separate PR?

Please see PR #1700.

ddabble added a commit to ddabble/django-simple-history that referenced this pull request May 29, 2024
Most of the changes to `pyproject.toml` were made by running
`hatch new --init` (see
https://hatch.pypa.io/latest/intro/#existing-project).
Most of the changes to the other files were based on the changes made in
django-commons/django-debug-toolbar#1690.

### `release.yml`:
* `hatch version` is run instead of `hatchling version` (as is done in
  the PR mentioned above), as the latter crashes with the error:
  ```
  hatchling.plugin.exceptions.UnknownPluginError: Unknown version source: vcs
  ```
  Installing `hatch` takes considerably longer than just `hatchling`,
  but I think it's still acceptable.
* Updated the `pypa/gh-action-pypi-publish` action from the sunset
  `master` branch to `release/v1`; see warning at
  https://github.com/jazzband/django-simple-history/actions/runs/9246937361.
  Also replaced the deprecated `repository_url` with `repository-url`; see
  https://github.com/pypa/gh-action-pypi-publish/blob/v1.8.14/action.yml#L15
### `.pre-commit-config.yaml`:
* Added some pre-commit hooks for formatting and validating
  `pyproject.toml`
### `MANIFEST.in`:
* Removed `MANIFEST.in`, as the default
  `[tool.hatch.build.targets.sdist]` configuration (in `pyproject.toml`)
  includes all files not ignored through our `.gitignore`; see
  https://hatch.pypa.io/latest/plugins/builder/sdist/#default-file-selection
### `pyproject.toml`:
* Didn't include the `license` field, as the docs recommend using a
  `License ::` classifier instead - see
  https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license
* The classifier "Programming Language :: Python :: 3"
  was changed to "Programming Language :: Python :: 3 :: Only"
  by the `pyproject-fmt` pre-commit hook
* Set `core-metadata-version = "2.2"` (copied from
  django-commons/django-debug-toolbar#1916) due to
  jazzband/help#360
* Didn't include the last 3 packages from the `packages` kwarg in
  `setup.py` when configuring `[tool.hatch.build.targets.wheel]`, since
  they don't make any difference in the generated wheel, as having just
  `simple_history` will include all its subpackages
* As part of porting long_description's file concatenation from
  `setup.py`, `hatch-fancy-pypi-readme` was added to `requires` and
  configured to concatenate the same files - except with the first title
  of `README.rst` and the "Unreleased" section of `CHANGES.rst` removed
  (facilitated by the added "Start of PyPI readme" comments in those two
  files)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants